| From: | Steffen Haeuser |
| Date: | 9 Sep 2001 at 00:09:11 |
| Subject: | Re: Hot Discussion :) |
Hi!
> > Ehm, not Warp3D speeded up the ports but the huge optimising by Hyperion
> > in the actual game code. You know without these parts (mainly memory
> > management) you'd have required 128+MB and virtual memory which is not
> > available in AmigaOS.
>
> Then we should use another 3d API instead? A faster one programmed by
> PowerUp authors? Warp3d is fast.
I do not think without the great work the Friedens and Sam did on Warp3D games would
be as fast on outdated Permedia 2 Hardware how the games in fact ARE BTW. They did
a wonder of a job there. And if anybody wanted to do another 3D API you'd
for a long time get less features and less speed, most likely. And probably bugs...
Remember, doing a 3D API with many Drivers is a LOT of work.
>
> By the way Warp3d is being converted to fully ppc by H&P.
Warp3D is actually fully 3D. Only parts where 68k is involved is in parts
where CGX/P96-functions are called (Locking for example). But even PPC-native
locking would probably only make 1-2 fps difference.
But then OS 4.0 will contain PPC-native
Ami2D/3D functionality (Ami3D being based on Warp3D like told by the Warp3D
team in some public discussion some times ago).
> Try warpmame.. it runs much smoother then PowerUp version. "MUCH MORE"
And actually WarpMAME bases on a later version of MAME - and with Mame later
versions are always slower... if it still is faster, well...
> >> PowerUp boards are badly designed hardware.. And Warpos makes best use of
> >> this. (Morphos is better.. But not fully functional.
> >
> > Define fully functional. WarpUp isn't. There are problems with IFusion and
> > BlizzardPPC cards because of a bug in WarpUp. H&P doesn't have a BlizzPPC
> > and has a limited knowledge about the hardware. So it's hard for them to
> > fix the bug.
>
> And this shows a problem with BlizzardPPC's. Am I wrong? They have limited
I thought so for some time. It might also be a problem in the way the
MMU-functions were called. It is easy to make mistakes there... as I do not
know the source in question I cannot really comment there, of course. But
I am sure this will still get fixed whereever the problem lies. After all
for the user it does not really matter WHERE the problem is as long as it
gets fixed.
> (But Morphos is better still I can scroll in Multiview increadibly fast :)
> and all those Morphos programs are nice) But emulated 68k is slower than my
> 060-50 :( I am sure another option exists. That makes full use of 68k and
> ppc without context switches)
Future WarpUP (or more likely OS 4) will at some point feature JIT 68k Emulation. Think of something
like MorphOS - a PPC Native OS - only this time based on WarpUP, and with a much
faster 68k Emulation... this is the goal we are heading to :) And as Alan Redhouse
pointed out once, with WarpOS compatibility to run "old" WarpOS programs on it.
> > H&P got a free PPC developer board and some more information about the
> > hardware to port StormC to PowerUp/elf. Instead they developed WarpUp.
> I'm glad.. Or I would be using PowerUp by now !!! (And Morphos would not
> have existed) I am glad
This needs some corrections... They definitely did not get information on how
to access the Chips of the PPC Board directly. They got the PowerUP API. And
after some tests this was not usable for applications (at least at that time, due to
a major bug) at all (this bug was fixed later). For developing powerpc.library
(the name WarpOS did not yet exist) they did not use ANYTHING reverse engineered
asides from some chipset addresses (which is probably 0.1% of the work involved !!!)
Actually WarpOS uses a totally different approach on Multitasking (Dynamic Scheduling)
than ppc.library, so reverse engineering would have been quite pointless, as it would
not helped at all, due to the different method used. Also the first version
of ppc.library did not use the Decrementer Interrupt for task changes (instead some slow
hacky method, though this code was rewritten later - actually soon after the first
WarpOS version using the Decrementer Interrupt was released - might be coincidental, though,
this timing... as Ralph Schmidt once pointed out in a public discussion the idea
using the decrementer interrupt is not that hard to come to... no need to reverse engineer
WarpOS from his side there either...). BTW: Before the kernel war really started H&P tried several
times to reach a compromise with Phase 5 (last time was that London show some years ago...
where an agreement with Wolf Dietrich was done about a common solution based on WarpOS
"with ppc.library Emulation" - this was still before Frank worked on the ppc.lib Emulation,
but as you know this agreement was broken (soon after the show RS released a version
of the FlashROM which broke WarpOS again, though Sam found a way around this problem quite soon).
But well, all that stuff is over a long time ago, and cannot be helped anymore *now*.
They should have come to a common point. Both parties.
> I am not sure about this one but Amiga told it is licenced from the company
> that was selling it.. (I think I read it somewhere. In amiga.com or
> haage-partner.de ..And that company hold the coprights of the software..
> If author of AmiTCP is correct ,, that company is the one to blame
Right.
> Hey: my 060-50 is faster on the net then my 040-25.. and 040-25 is faster
> than 030-50. So I think it is logical AmigaOS4 is faster on the net..
> (I think (but am not sure) TCPI/ IP and LAN support is integrated into
> setpatch in AmigaOS4
Added to this, the contextswitch problem is in most cases really overrated. Okay,
for some sorts of software it IS a factor... but in most cases you are better of
with the faster CPU, like you told already.
Steffen
______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1